Repository navigation
fix(astro-renderer): no dataDir in the cloudflare target's config (#239) - #240
Merged
Merged
Conversation
RFC-0046 §11b classes cloudhal.json dataDir as runtime: the Site Worker reads D1 and R2 through its bindings (runtime-workerd.ts ignores the field), but the integration still baked the resolved value, the build machine's absolute path, into virtual:cloudhal/config, so a release bundle built in CI carried it to every deployment. The cloudflare target now gets the config without dataDir (virtualConfig); Node targets keep it. - astro-renderer test: the module has no dataDir on cloudflare, whatever cloudhal.json says, and keeps it on node. - cli workerd test: two starter builds that differ only in dataDir are the same bytes (Astro's per-build key pinned with ASTRO_KEY), neither carries the path, and the built Worker serves the site with no data directory on disk. Without the fix the first two fail. - RFC-0046 §11b cites the guard. Closes #239 Co-Authored-By: Claude Opus 5.5 <[email protected]> Signed-off-by: Madraka <[email protected]>
Madraka
force-pushed
the
claude/datadir-guard-239
branch
from
November 15, 2026 07:04
3c8870f to
4cb3ac6
Compare
- virtual:cloudhal/config is typed VirtualCloudhalConfig (dataDir optional, exported) in astro-renderer's astro-env.d.ts and the starter's env.d.ts; getSource and peerEditions take it, and the Node paths that need dataDir say so when it is missing (nodeDataDir, the comments middleware). - RFC-0046 §11b and the changeset say no dataDir path reaches a bundle (Astro's own manifest still carries its root, src and out URLs), and that bundles are not byte-reproducible by design: Astro's random per-build key stays unpinned in the release build, as a fixed one would be published. - cloudflare-datadir.test scans the first build for its own path before the second build replaces dist. Refs #239 Co-Authored-By: Claude Opus 5.5 <[email protected]> Signed-off-by: Madraka <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
RFC-0046 §11b classes
cloudhal.jsondataDiras runtime fordeploy --release: the Site Worker never reads it. The integration still baked it in, though.astro:config:setupresolvesdataDirto an absolute path and puts it intovirtual:cloudhal/configon every target. So a release bundle built in CI carried the CI runner's absolute path to every deployment.Fix (
packages/astro-renderer/src/integration.ts):virtualConfig(resolved, cloudflare)dropsdataDirfrom the virtual module on thecloudflaretarget. Node targets (cloudhal dev, static builds) keep it:runtime.ts, the comments middleware and thestatic-*writers read the local store from it.Why nothing on the cloudflare target needs it:
@cloudhal/astro-renderer/runtime, which resolves toruntime-workerd.tsunder theworkerdcondition, and that file ignoresdataDir(bindings decide);astro:build:donereturns before thestatic-*writers.The workerd suites below confirm it.
Tests (run alone, one at a time; load stayed below 5.2)
astro-renderer/test/virtual-config.test.ts(new, 2 tests): it runsastro:config:setupand loads the virtual module.cloudflarethe module has nodataDirand no path, for a relative, an absolute and anotherdataDir, and it is the same bytes for each.nodethe module keeps the resolved path.cli/test/cloudflare-datadir.test.ts(new, 3 tests, real starter builds and workerd):dataDir(.cloudhal, then a nonexistent absolute path) are the same bytes across all 112 files;/and/posts/hello-worldafter the data directory has been moved off disk.key(it encrypts server-island and action props) unlessASTRO_KEYis set. The test pins it, so the two builds can be compared. With the key pinned, the build is deterministic.cloudflare10,cloudflare-deploy3,cloudflare-gates9,cloudflare-analytics9,cloudflare-comments8,cloudflare-status6,cloudflare-multisite6,cloudflare-schedules4;astro:config:setuphook, which is 32 on main too.Review round 1
virtual:cloudhal/configis now typed asVirtualCloudhalConfig(Omit<CloudhalRendererConfig, "dataDir"> & { dataDir?: string }, exported), the same shapevirtualConfigreturns. Both declarations use it: astro-renderer'sastro-env.d.tsand the starter'ssrc/env.d.ts. So theme code that readsdataDirmust handle its absence.getSourceandpeerEditions(both runtimes) take that type.dataDirsay so when it is missing, instead of readingundefined:nodeDataDirinruntime.ts, and the comments middleware.dataDirpath reaches a bundle. They note that Astro's own serialized manifest still carries its root, source and output directories asfile://URLs.ASTRO_KEY, to compare its two builds.cloudflare-datadir.test.tsnow scans the first build for its own data path before the second build replacesdist.turbo run typecheck: 22/22;cloudflare-datadir3,cloudflare10,release-theme-check8,deploy-release24;demo:archive --check, size and biome are clean.RFC-0046 §11b now cites this guard. Changeset:
@cloudhal/astro-rendererpatch.Closes #239
🤖 Generated with Claude Code